Перед проходившей недавно конференцией VMworld 2019 компания VMware объявила об обновлении платформы VMware HCX Enterprise, которая теперь позволяет проводить миграции с различных опремизных инфраструктур (на базе как vSphere, так и Hyper-V или KVM) в облако на базе VMware vCloud. Давайте посмотрим, как устроено это решение.

Ранее VMware HCX (расшифровывается как Hybrid Cloud Extension) мог сопровождать процессы миграции виртуальных машин vSphere из локального датацентра в облачную инфраструктуру сервис-провайдеров VCPP или публичных облаков, но теперь это гораздо более функциональное средство - для миграции поддерживаются гипервизоры RedHat OpenStack/KVM и Microsoft Hyper-V. Для этого есть специальные дата муверы, которые обеспечивают процесс, называемый OS Assisted Migration (OSAM).

Много лет назад для миграций на уровне собственного датацентра можно было использовать  VMware Converter (продукт, который был незаслуженно забыт), но теперь VMware HCX Enterprise дает гораздо более широкие возможности по созданию уже гибридных инфраструктур за счет перемещения части виртуальных машин в облако и обслуживания единого пространства для существования машин в гибридной среде.

VMware HCX работает с vSphere 5.5 и более поздними версиями, а также гипервизорами KVM и Hyper-V, чтобы создать единую среду между онпремизным датацентром и облачным на основе архитектуры VMware Cloud Foundation (VCF), где работают средства по обеспечению катастрофоустойчивости рабочих нагрузок VMware Site Recovery Manager. Кстати, самыми крупными партнерами VMware в рамках программы VCPP являются IBM, OVH и Centurylink, а поддерживаемыми публичными облаками - AWS, Azure и GCP.

VMware HCX может быть первым шагом для крупных компаний в плане начала создания гибридной инфраструктуры, которая использует ресурсы нескольких облаков (то, что на картинке выше обозначено как v5). Ведь уже сейчас пользователи испытывают потребность облачных ресурсах больших публичных облаков, а также сторонних специализированных облаках, таких как Telco Clouds (на базе решений SDN / NFV).

HCX предоставляет возможность миграции виртуальных машин и приложений между различными видами облаков по принципу Any2Any. С точки зрения виртуальной машины, ее ОС и приложений, HCX выступает уровнем абстракции, который представляет машине единую гибридную среду в которой находятся все локальные и облачные ресурсы (infrastructure hybridity). Это дает возможность машинам перемещаться между датацентрами, не требуя реконфигурации самих ВМ или инфраструктуры.

Решение HCX представлено двумя компонентами:

• HCX Cloud (Target) – это машина HCX Management, которая развернута, например, в облаке VMC on AWS SDDC.
• HCX Enterprise (Source) – это ВМ, которая развертывается в онпремизном датацентре клиента.

Если вы пользуетесь услугами облака VMware vCloud on AWS, то HCX Cloud у вас готов к использованию (надо только нажать кнопку Deploy в консоли VMC). После этого вы сможете использовать HCX cloud web console, где можно скачать готовый виртуальный модуль HCX Enterprise OVA для использования уже в онпремизном датацентре. После создания конфигурации из локальной и облачных сред между ними автоматически настраивается IPsec VPN.

После этого вы сможете управлять гибридной средой с помощью HCX Manager:

HCX Enterprise в онпремизном датацентре отвечает за выполнение следующих задач:

• Создание интегрированной среды управления vCenter между облаком и онпремизным датацентром.
• Соединение площадок в единое облако HCX Cloud.
• Развертывание дополнительных компонентов (сервисных виртуальных модулей). Эти компоненты автоматически развертываются и в облаке AWS одновременно с онпремизными:
  • HCX WAN Interconnect - проводит миграцию vMotion между площадками через интернет или выделенные линии. Он также отвечает за обеспечение безопасности и шифрования. С точки зрения vCenter, это выглядит как фейковый ESXi-хост на обеих площадках, действующий как прокси для миграции ВМ между сайтами.
  • HCX WAN Optimization - отвечает за оптимизацию канала средствами дедупликации и компрессии трафика.
  • HCX Network Extension - реализует расширение L2-адресации на единое пространство с облаком, чтобы машины при миграции не требовали перенастройки MAC и IP-адресов.
• Предоставление Restful API и HCX API (к документации можно получить доступ по адресу https://<HCX Enterprise>/hybridity/docs).

На стороне публичного облака, например, vCloud on AWS, это выглядит несколько более сложно (там задействуется решение VMware NSX для обеспечения сетевой инфраструктуры), но компоненты те же:

Для инфраструктуры на базе VCPP (например, в облаке IBM) все выглядит проще (но там несколько меньше возможностей для конфигурации сетевого стека):

Помимо перечисленных основных 3 компонентов, HCX реализует еще несколько полезных сервисов, таких как пакетная миграция ВМ, средства катастрофоустойчивости (Disaster Recovery), возможности миграции с других гипервизоров (OS Assisted Migration) и прочее:

При миграции виртуальных машин между площадками есть пять типов миграций:

• VMware HCX Bulk Migration - этот метод использует средства VMware vSphere Replication для массового перемещения виртуальных машин на удаленную площадку. Потом происходит переключение обслуживания на реплики, что эквивалентно простою сервиса на период перезагрузки ВМ.
• VMware HCX vMotion - здесь применяются обычные средства vMotion для перемещения ВМ (1 машина в один момент времени, без перерыва в обслуживании).
• VMware HCX Cold Migration - это миграция остановленной машины с источника на таргет, с максимальными гарантиями сохранности данных, но простоем сервиса.
• VMware HCX Replication Assisted vMotion (RAV) - эта техника совмещает в себе преимущества HCX Bulk Migration (параллелизм операций и возможность запланированного запуска) с HCX vMotion (без прерывания сервиса). Это новый режим, появившийся в августе этого года.
• VMware HCX OS Assisted Migration - это миграция виртуальных машин с не-vSphere гипервизоров на онпремизную или облачную инфраструктуру vSphere (также новая функция HCX Enteprise).

Для мониторинга решения HCX можно использовать специальный пакет vRealize Operations Management Pack for HCX, который предоставляет интегрированные дэшборды и отчеты, а также дает всю необходимую информацию о возникающих проблемах.

Более подробно о решении HCX можно узнать на основной странице продукта. Администраторам гибридных инфраструктур VMware vSphere, использующих ресурсы различных облаков, стоит присмотреться к этому решению, так как оно существенно упрощает контроль над виртуальными машинами, которые перемещаются между датацентрами (и, конечно же, создает платформу для всего этого), а также позволяет своевременно отслеживать и решать возникающие проблемы.

Оригинал статьи на английском языке в блоге StarWind Software.

Продолжаем рассказывать (пока еще есть что!) о новых продуктах и технологиях, анонсированных на конференции VMworld 2019, которая закончилась уже почти 3 недели назад. Одна из самых интересных и перспективных технологий - это, конечно же, техника VMware Cluster Memory, которая действительно может поменять архитектуру датацентров в будущем.

Об этой технологии хорошо написал Дункан Эппинг. Как известно некоторым из вас, еще 20 лет назад скорость доступа к оперативной памяти серверов была примерно в 1000 раз выше, чем доступ к данным другого хоста по локальной сети. Шли годы, сетевой стек и оборудование улучшались - и в итоге на сегодняшний день доступ по сети всего в 10 раз медленнее, чем локальный доступ к RAM. Достигается это различными способами, в том числе технологией удалённого прямого доступа к памяти (remote direct memory access, RDMA).

Главное в этой эволюции то, что такие вещи как RDMA стали вполне доступными по цене, а значит можно обсуждать новые архитектуры на их основе. Тем более, что одной из основных проблем текущих датацентров стала трудность масштабирования инфраструктуры по памяти - ведь когда на одном из хостов не влезают виртуальные машины по RAM (например, есть машины с очень большим потреблением памяти), нужно увеличивать память и на всех остальных хостах кластера.

Поэтому VMware в рамках сессии VMworld "Big Memory with VMware Cluster Memory" рассказала о том, как можно строить кластеры с помощью так называемых "серверов памяти", которые обеспечивают работу хостов ESXi и их виртуальных машин, которым нужно дополнительное пространство памяти по требованию.

Кстати, еще есть и ограничение по объему DRAM на одном хосте - как правило, это несколько ТБ. Как мы видим на картинке выше, эту проблему можно решить созданием отдельных Memory-серверов в кластере, которые могут раздавать свою память по высокопроизводительной шине RDMA.

Технологии сетевого доступа к памяти будут развиваться, и скоро возможность использования виртуальными машинами страниц памяти с Memory-хостов будет вполне реальна:

Для этого компания VMware разработала отдельный paging-механизм, который позволяет проводить паджинацию страниц на удаленный сервер вместо локального диска, для чего будет необходим локальный кэш. При запросе страницы с удаленного сервера она сначала будет помещаться в локальный кэш для ускорения повторного использования.

Если страницы долгое время остаются невостребованными - они перемещаются обратно на Memory Server. По-сути, эта технология представляет собой оптимизацию механизма паджинации. В то же время, здесь пока существуют следующие проблемы:

• Сбои, связанные с доступом к Cluster Memory
• Безопасность и сохранность данных
• Управление ресурсами в распределенной среде
• Увеличение потребления межсерверного канала
• Управление жизненным циклом страниц
• Производительность механизма в целом

В рамках демо на VMworld 2019 была показана технология Cluster Memory в действии для виртуальной машины, использующей 3 ГБ такой памяти.

Конечно же, самая интересная проблема - это производительность ВМ в таких условиях. VMware сделала некоторые тесты, где были использованы различные соотношения локальной и удаленной памяти. На получившемся графике видна производительность в числе выполненных операций в минуту:

Обратите внимание, и это здесь четко видно, что Cluster Memory всегда работает быстрее, чем локальный SSD-Swap. Второй важный момент тут, что даже при 70% использовании удаленной памяти виртуальная машина, с точки зрения производительности, чувствует себя вполне хорошо.

Понятно, что технология VMware Cluster Memory еще дело будущего, но пока вы можете посмотреть интересную запись упомянутой сессии на VMworld.

Продолжаем рассказывать об анонсах продуктов и технологий, представленных на конференции VMworld 2019, так как есть о чем еще говорить. Одним из главных анонсов для сервис-провайдеров на мероприятии стала доступность платформы VMware Cloud Foundation for Cloud Providers.

Напомним, что vCloud Foundation (VCF) - это комплексное программное решение, которое включает в себя компоненты VMware vRealize Suite, VMware vSphere Integrated Containers, VMware Integrated OpenStack, VMware Horizon, NSX и другие, работающие в онпремизной, облачной или гибридной инфраструктуре предприятия, которые желательно развертывать все вместе, но можно какие-то и опустить. Важно, что в рамках этой архитектуры полностью поддерживается взаимодействие всех компонентов друг с другом, поэтому для VCF есть список продуктов и их версий (и это могут быть не самые последние версии), который и составляет архитектуру VCF. Напомним, что о версии VCF 3.0 мы писали вот тут.

Представленная архитектура VCF для сервис-провайдеров (VCPP) позиционируется как главный продукт для построения выделенных облачных инфраструктур для крупных клиентов (Dedicated Private Clouds). Решение комбинирует в себе возможности платформ VMware Software-Defined (vSphere и прочие продукты) и решения для миграции в виртуальную среду HCX. Облачная платформа VCF поставляется в трех изданиях, в зависимости от изданий входящих в него продуктов (подробнее об этом тут):

VMware Cloud Foundation соединяет в себе портфолио SDDC (vSphere, NSX, vSAN), а также средства управления SDDC Manager, что позволяет создать валидированную архитектуру на стороне сервис-провайдера и обеспечить управление жизненным циклом всех компонентов, чтобы облачные провайдеры могли запускать апгрейд всей инфраструктуры в один клик.

Кстати, решение VCF можно потестировать вживую в рамках лабораторной работы Hands-on Lab.

Онбординг пользователей в облачную среду провайдеров VCPP помогает производить решение VMware HCX, которое обеспечивает процесс миграции физических ресурсов предприятия в облачную среду на базе виртуальных машин в облаке:

Надо сказать, что решение VCF может работать поверх гибридной инфраструктуры предприятия - просто в облаке сервис-провайдера появляется еще один объединяющий элемент. Для традиционных хостинг-провайдеров, которые предоставляют услуги Shared Hosting / Virtual Private Servers, решение VCF для VCPP позволит получить крупных заказчиков, при этом оно изначально заточено под выделенную инфраструктуру со множеством клиентов.

Для старта с решением VMware Cloud Foundation for Cloud Providers партнерам потребуется пройти специальное обучение в течение 1 недели.

Вторым важным анонсом стал выпуск архитектуры vCloud Foundation версии 3.8.1. Надо сказать, что этот релиз сфокусирован на инфраструктуре контейнеризованных приложений под управлением Kubernetes. Такая инфраструктура управляется совершенно иначе, по сравнению с традиционной платформой для виртуальных машин, поэтому целью было объединить рабочие процессы PKS (Pivotal Container Service) и VCF.

В этом релизе у VCF 3.8.1 появились следующие новые возможности:

• Автоматизация развертывания решения PKS - теперь можно автоматически разместить нагрузку VMware Enterprise PKS в домене рабочей нагрузки NSX-T.

Средства интеграции VCF и PKS построены таким образом, что администраторам облака не требуется никаких специальных знаний в области Kubernetes, чтобы управлять интегрированной инфраструктурой контейнеров и виртуальных машин. Подробнее об этом рассказано тут.

• Поддержка двухфакторной аутентификации - теперь она доступна для API на базе паролей в консоли SDDC Manager.
• Улучшенные возможности Phone Home - предоставляет возможность провайдеру организовать функции phone home для данных в SDDC Manager одним кликом.
• Обновленные списки версий ПО (Bill of materials, BOM) - включают в себя vSphere 6.7 Update 3, vSAN 6.7 U3, новые версии Horizon, NSX-T и vRealize.

• Улучшения безопасности и исправления ошибок.

Более подробно о новых возможностях VCF можно узнать из Release Notes.

На конференции VMworld 2019, которая недавно прошла в Сан-Франциско, было представлено так много новых анонсов продуктов и технологий, что мы не успеваем обо всех рассказывать. Одной из самых интересных новостей стала информация про новую версию распределенного планировщика ресурсов VMware Distributed Resource Scheduler (DRS) 2.0. Об этом было рассказано в рамках сессии "Extreme Performance Series: DRS 2.0 Performance Deep Dive (HBI2880BU)", а также про это вот тут написал Дункан Эппинг.

Надо сказать, что технология DRS, позволяющая разумно назначать хосты ESXi для виртуальных машин и балансировать нагрузку за счет миграций ВМ посредством vMotion между серверами, была представлена еще в 2006 году. Работает она без кардинальных изменений и по сей день (13 лет!), а значит это очень востребованная и надежная штука. Но все надо когда-то менять, поэтому скоро появится и DRS 2.0.

Если раньше основным ресурсом датацентров были серверы, а значит DRS фокусировался на балансировке ресурсов в рамках кластера серверов ESXi, то теперь парадигма изменилась: основной элемент датацентра - это теперь виртуальная машина с приложениями, которая может перемещаться между кластерами и физическими ЦОД.

Сейчас технология DRS 2.0 находится в статусе Technical Preview, что значит, что никто не гарантирует ее присутствие именно в таком виде в будущих продуктах VMware, кроме того нет и никаких обещаний по срокам.

В целом, изменилось 3 основных момента:

• Появилась новая модель затраты-преимущества (cost-benefit model)
• Добавлена поддержка новых ресурсов и устройств
• Все стало работать быстрее, а инфраструктура стала масштабируемее

Давайте посмотрим на самое интересное - cost-benefit model. Она вводит понятие "счастья виртуальной машины" (VM Happiness) - это композитная метрика, которая формируется из 10-15 главных метрик машин. Основные из этого числа - Host CPU Cache Cost, VM CPU Ready Time, VM Memory Swapped и Workload Burstiness.

VM Happiness будет основным KPI, которым будет руководствоваться DRS 2.0 при проведении миграций (то есть цель - улучшить этот показатель). Также эту оценку можно будет увидеть и в интерфейсе. Помимо этого, можно будет отслеживать этот агрегированный показатель и на уровне всего кластера VMware HA / DRS.

Второй важный момент - DRS 2.0 будет срабатывать каждую минуту, а не каждые 5 минут, как это происходит сейчас. Улучшение связано с тем, что раньше надо было снимать "снапшот кластера", чтобы вырабатывать рекомендации по перемещению виртуальных машин, а сейчас сделан простой и эффективный механизм - VM Happiness.

Отсюда вытекает еще одна полезная функциональность - возможность изменять интервал опроса счастливости виртуальных машин - для стабильных нагрузок это может быть, например, 40-60 минут, а для более непредсказуемых - 15-20 или даже 5.

Еще одна интересная фича - возможность проводить сетевую балансировку нагрузки при перемещении машин между хостами (Network Load Balancing). Да, это было доступно и раньше, что было вторичной метрикой при принятии решений о миграции посредством DRS (например, если с ресурсами CPU и памяти было все в порядке, то сетевая нагрузка не учитывалась). Теперь же это полноценный фактор при принятии самостоятельного решения для балансировки.

Вот пример выравнивания такого рода сетевой нагрузки на виртуальные машины на разных хостах:

Модель cost-benefit также включает в себя возможности Network Load Balancing и устройства PMEM. Также DRS 2.0 будет учитывать и особенности аппаратного обеспечения, например, устройства vGPU. Кстати, надо сказать, что DRS 2 будет также принимать во внимание и характер нагрузки внутри ВМ (стабильна/нестабильна), чтобы предотвратить "пинг-понг" виртуальных машин между хостами ESXi. Кстати, для обработки таких ситуаций будет использоваться подход "1 пара хостов source-destination = 1 рекомендация по миграции".

Также мы уже рассказывали, что в настоящее время пользователи стараются не допускать переподписку по памяти для виртуальных машин на хостах (memory overcommit), поэтому вместо "active memory" DRS 2.0 будет использовать параметр "granted memory".

Ну и был пересмотрен механизм пороговых значений при миграции. Теперь есть следующие уровни работы DRS для различных типов нагрузок:

• Level 1 – балансировка не работает, происходит только выравнивание нагрузки в моменты, когда произошло нарушение правил DRS.
• Level 2 – работает для очень стабильных нагрузок.
• Level 3 – работает для стабильных нагрузок, но сфокусирован на метрике VM happiness (включено по умолчанию).
• Level 4 – нагрузки со всплесками (Bursty workloads).
• Level 5 – динамические (Dynamic) нагрузки с постоянными изменениями.

В среднем же, DRS 2.0 обгоняет свою первую версию на 5-10% по быстродействию, что весьма существенно при больших объемах миграций. При этом VMware понимает, что новый механизм DRS второй версии может родить новые проблемы, поэтому в любой момент можно будет вернуться к старому алгоритму балансировки с помощью расширенного параметра кластера FastLoadBalance=0.

По срокам доступности технологии DRS 2.0 информации пока нет, но, оказывается, что эта технология уже почти год работает в облаке VMware Cloud on AWS - и пока не вызывала нареканий у пользователей. Будем следить за развитием событий.

В рамках серии анонсов, представленных на прошедшей конференции VMworld 2019, компания VMware представила интересное средство, которое может оказаться полезным администраторам виртуальной инфраструктуры - vSphere Assessment Tool (vSAT).

Главное назначение этой утилиты - помочь ИТ-специалистам перед миграцией инфраструктуры VMware vSphere на новую версию: заранее понять потенциальные проблемы с виртуальными машинами после апгрейда и проанализировать общую готовность инфраструктуры к обновлению. Также можно выявить возможные трудности в плане поддержки аппаратного обеспечения, что очень важно, когда у вас либо очень старое, либо очень новое оборудование.

Утилита vSAT реализована двумя компонентами:

• Десктопный клиент, который связывается с сервером vCenter и организует передачу данных.
• Онлайн-портал vSphere Assessment Portal, обрабатывающий ваши данный и визуализующий результаты.

Для начала работы просто нажимаете Get Started на первой странице портала:

Десктопный клиент поддерживает ОС Windows, OS X и Linux. В клиенте вы просто добавляете сервер vCenter, который нужно проанализировать. Для этого либо потребуется использовать административный аккаунт, либо создать пользователя с кастомной ролью с привилегиями "Host Settings".

После того, как в вашей инфраструктуре завершен сбор данных, есть 2 способа отправить их в облако:

• Онлайн-отправка на vSphere Assessment portal с использованием vSAT passcode (чтобы его получить, можно использовать опцию клиента "Forgot Your vSAT passcode?").

Также Passcode можно получить из меню аккаунта на vSAT Portal:

• Офлайн-отправка путем скачивания данных в файл и их последующая загрузка на портал в ручном режиме:

Результатом анализа будет дэшборд, на котором представлена сводная информация по имеющимся проблемам для выбранного пути апгрейда. В левой панели можно выбрать нужный хост ESXi (по аналогии с vSphere Client).

В представлении Summary вы найдете список всех версий vSphere, на которые вы можете выполнить миграцию, а также узнать, какие хосты ESXi рискуют оказаться в неподдерживаемой конфигурации. При клике на хост ESXi возникает панель host details, где можно увидеть текущую версию vSphere, модель сервера, сетевые адаптеры и контроллеры хранилищ. Для каждого компонента верифицируется поддержка соответствующей версией vSphere.

В общем, очень полезная штука для админа перед обновлением vSphere на новую версию. Особенно полезно будет запустить ее в большой инфраструктуре, где присутствует различное оборудование и, возможно, разные версии хостов ESXi.

Пользуйтесь!

Многие из вас следят за новостями и событиями конференции VMworld 2019, которая проходит в эти дни в Сан-Франциско. Одним из первых и важных анонсов конференции стало объявление о скором выпуске проекта VMware Tanzu. Те из вас, кто следит в последнее время за новыми релизами от VMware, знают, что компания выпускает очень много чего интересного для инфраструктуры контейнеризованных приложений Kubernetes.

Например, совсем недавно мы писали о новой подсистеме хранения для K8s - Cloud Native Storage (CNS), утилите для контроля и мониторинга состояния кластеров VMware Octant, а также средстве для управления инфраструктурой контейнеров приложений VMware Enterprise PKS 1.5 (Pivotal Container Service).

На данный момент свежепоявившееся семейство Tanzu представлено двумя продуктами:

• Project Pacific — набор средств для преобразования среды VMware vSphere в нативную платформу для кластеров Kubernetes (будет доступно в следующих релизах vSphere).
• VMware Tanzu Mission Control - единая операционная консоль для кластеров Kubernetes, которая позволит контролировать все аспекты жизненного цикла приложений.

Project Pacific

Project Pacific сейчас находится в статусе технологического превью. Это средство представляет собой набор инструментов, который позволяет преобразовать платформу vSphere в средство нативного исполнения приложений в среде Kubernetes.

Данный продукт будет решать следующие задачи:

• Использование vSphere для нативной среды Kubernetes
• Предоставление средств управления, сфокусированных на приложениях
• Возможность взаимодействия команд разработки и администрирования/оперирования

С помощью Pacific разработчики продолжат управлять приложениями посредством Kubernetes, но сами приложения за счет этого будут "комфортно себя чувствовать" на платформе ESXi. Администраторы же смогут выполнять рутинные задачи через средства управления VMware vCenter.

Так как подразумевается, что Kubernetes будет нативно работать в среде vSphere, то будет поддерживаться концепция пространств имен в рамках инфраструктуры vSphere. Пространства имен в K8s - это коллекции объектов (контейнеры, виртуальные машины, диски и т.п.).

На уровне пространств имен в среде K8s можно выполнять стандартные для vSphere операции, такие как контроль и выделение ресурсов, vMotion, шифрование, HA и снапшоты.

VMware Tanzu Mission Control

Tanzu MC дает менеджерам и администраторам датацентров средства для создания и развертывания новых приложений на платформе Kubernetes, а также дает управлять кластерами K8s из единой точки. Таким образом, команды разработки могут запросить нужные ресурсы, когда им требуется, и получить их самым быстрым и оптимальным образом.

Платформа Tanzu Mission Control полностью построена на базе универсального API, который могут использовать разработчики для оперирования кластерами Kubernetes через Cluster API. Это касается всех рабочих процессов (например, создание или обновление кластера), а также аутентификации и прочих вспомогательных сервисов.

Сама консоль - это SaaS-решение, которое объединяет объекты разной природы в облачной консоли (например, это могут быть компоненты платформы vSphere, объекты из публичных облаков, средства OpenShift или просто самопальные инсталляции собственной архитектуры). Также вы можете привязать кластер VMware Essential PKS к консоли Tanzu Mission Control и использовать средства автоматизации обслуживания жизненного цикла кластеров, либо можно открыть и использовать расширенные средства сервисов PKS-кластера.

Консоль Mission Control использует:

• Cluster API для управления жизненным циклом (Lifecycle Management)
• Velero для резервного копирования и восстановления
• Sonobuoy для контроля конфигураций
• Contour для контроля компонентов ingress

Также все кластеры и их объекты покрываются гибко настраиваемыми политиками. Их можно применять к кластерам и группам кластеров, разграничивая таким образом зоны ответственности между разработчиками.

Ну и одно из самых удобных для оператора - это федерация данных кластеров K8s из разных источников в единой консоли:

Более подробно о проекте Tanzu можно почитать в пресс-релизе VMware.

Как вы знаете, недавно обновленная платформа виртуализации VMware vSphere 6.7 Update 3 стала доступной для загрузки. Одновременно с этим компания VMware сделала доступной для скачивания и развертывания систему отказоустойчивых кластеров хранилищ VMware vSAN 6.7 Update 3. В обоих этих решениях появилась встроенная поддержка технологии Cloud Native Storage (CNS), о которой мы сегодня расскажем.

Итак, Cloud Native Storage (CNS) - это функциональность VMware vSphere и платформы оркестрации Kubernetes (K8s), которая позволяет по запросу развертывать и обслуживать хранилища для виртуальных машин, содержащих внутри себя контейнеры. По-сути, это платформа для управления жизненным циклом хранения для контейнеризованных приложений.

При этом для такого управления сделано специальное представление в интерфейсе vCenter, которое вы видите на картинке выше.

Основная задача CNS - это обеспечивать развертывание, мониторинг и управление хранилищами для Cloud Native Applications (CNA), то есть современных приложений, исполняемых в контейнерах Docker под управлением Kubernetes (но, кстати, в будущем возможна поддержка и таких платформ, как Mesos и Docker Swarm).

Архитектура CNS реализована двумя компонентами:

• Интерфейс Container Storage Interface (CSI), представляющий собой плагин для K8s.
• Консоль управления CNS Control Plane на сервере vCenter, доступная через vSphere Client.

Через консоль управления CNS администратор может получить представление об имеющихся хранилищах в среде K8s (и видеть маппинги хранилищ на виртуальные диски VMDK), а также управлять ими в большом масштабе, что очень сложно при оперировании на уровне отдельных контейнеров, так как их могут быть сотни на одном хосте ESXi.

Кстати, про оперирование CNS есть интересное видео от VMware:

Надо понимать, что технология CNS появилась не впервые. Ранее подобные функции реализовывал механизм vSphere Storage for Kubernetes (он же vSphere Cloud Provider, VCP). Проект VCP появился как результат внутреннего хакатона VMware, когда требовалось быстро сделать драйвер для кластеров Kubernetes.

До этого приходилось вручную монтировать хранилища контейнеров на виртуальные диски VMDK, что было крайне неудобно, а при большом количестве контейнеров - практически нереально.

Сейчас архитектура VCP реализуется такими решениями Kubernetes as a Service (KaaS), как VMware PKS, RedHat OpenShift, Google Cloud Anthos и Rancher. Для этой архитектуры было возможно 2 режима развертывания - "in-tree" и "out-of-tree". В первом случае VCP был интегрирован в дистрибутив Kubernetes и развертывался одновременно с ним, а во втором - подразумевал последующую интеграцию после развертывания K8s.

Ввиду того, что обновлять VCP при первом варианте развертывания можно было только одновременно с K8s, вариант "in-tree" был исключен из конфигурации развертывания Kubernetes. VMware использовала эту ситуацию для того, чтобы полностью переписать код VCP (который, скорее всего, был не самым оптимальным еще с хакатона) и получить новую архитектуру - CNS.

Также кстати оказалась и покупка компании Heptio (об этом мы упоминали вот тут) - в итоге VMware интегрировала решение CNS прямо в платформу vSphere, без необходимости что-либо развертывать дополнительно. Мало того, архитектура CNS поддерживает любой оркестратор контейнеров, построенный на базе спецификации CSI.

Таким образом, CNS Control Plane на сервере vCenter брокеризует соединение с плагином (на данный момент только для K8s), который уже взаимодействует на уровне Kubernetes.

Частью решения CNS являются First Class Disks (FCDs), о которых мы рассказывали вот тут. Они были придуманы для того, чтобы управлять сервисами, заключенными в VMDK-диски, но не требующими виртуальных машин для своего постоянного существования. Это очень удобно для контейнеров, так как их можно динамически привязывать и отвязывать, не оставляя после себя "осиротевших" VMDK.

Кроме всего этого, CNS полностью подчиняется политикам Storage Policy-Based Management (SPBM), а это значит, что инфраструктура таких хранилищ отлично согласуется с пространством ярусного хранения VMware vSAN и концепцией K8s StorageClass. Также CNS, конечно же, работает и с классическими хранилищами VMFS и NFS, что позволяет использовать политики SPBM на базе тэгов.

Надо отметить, что технология CNS доступна для всех пользователей VMware vSphere, начиная с издания Standard, поэтому платить отдельно за нее не придется. Ну и в заключение обзорное видео о том, что такое и как работает Cloud Native Storage:

Скачать VMware vSphere 6.7 Update 3 с интегрированной технологией CNS можно по этой ссылке.

Недавно на сайте проекта VMware Labs обновилась одна из самых полезных утилит для администраторов хранилищ VMware vSphere – IOBlazer. Она позволяет сгенерировать нагрузку на хранилища с любых платформ - Linux, Windows и Mac OS, при этом администратор может задавать паттерн нагрузки с высокой степенью кастомизации, что очень важно для реального тестирования подсистемы хранения для виртуальных машин.

Вчера мы писали о том, что в перед предстоящим VMworld 2019 компания VMware рассказала о новых возможностях решения для организации отказоустойчивых кластеров хранилищ VMware vSAN 6.7 Update 3. Одновременно с этим была анонсирована и новая версия главной платформы виртуализации VMware vSphere 6.7 Update 3.

Напомним, что прошлая версия - vSphere 6.7 Update 2 - вышла весной этого года. Давайте посмотрим, что нового будет в vSphere 6.7 U3:

1. Поддержка нескольких vGPU (от NVIDIA) для одной виртуальной машины.

Теперь vSphere поддерживает несколько устройств NVIDIA GRID virtual GPU (vGPU), привязанных к одной виртуальной машине. Это, прежде всего, даст возможность увеличения вычислительных мощностей для тяжелых нагрузок, предъявляющих высокие требования к расчетам графического процессора (например, задачи машинного обучения).

2. Поддержка AMD EPYC Generation 2.

Новый релиз vSphere будет полностью совместим с поколением процессоров AMD EPYC. VMware и AMD работают в тесном сотрудничестве в целях поддержки самых последних нововведений в плане безопасности и производительности, заявленных в последних моделях данной линейки CPU.

3. Возможность изменить PNID для vCenter.

Идентификатор PNID (Primary Network IDentifier) сервера vCenter Server - это его сетевое имя (оно же FQDN), которое задается на этапе установки. Теперь есть возможность изменить его прямо в интерфейсе:

4. Поддержка Dynamic DNS (DDNS).

Dynamic DNS - это механизм обновления записей DNS-серверов новыми данными при изменении IP-адресов хостов. Ранее при использовании динамических IP для vCenter Server appliance (VCSA), в случае, если адрес менялся, приходилось вручную обновлять DNS-записи (собственно, поэтому никто и не использовал динамические IP). Теперь же с поддержкой DDNS этот процесс автоматизирован.

5. Улучшения поддержки драйверов.

Для сетевого драйвера VMXNET3 версии 4 были добавлены следующие возможности:

• Guest encapsulation offload and UDP (расчет контрольных сумм)
• Поддержка ESP RSS для стека Enhanced Networking Stack (ENS)

Также было обновлено множество драйверов, например, в драйвере ixgben появились функции queue pairing для оптимизации производительности CPU, а в драйвере bnxtnet добавилась поддержка адаптеров Broadcom 100 GbE и потоков multi-RSS.

Вот полный список обновленных драйверов:

• VMware nvme
• Microchip smarpqi
• Marvell qlnativefc
• Broadcom lpfc/brcmfcoe
• Broadcom lsi_msgpt2
• Broadcom lsi_msgpt35
• Broadcom lsi_msgpt3
• Broadcom lsi_mr3
• Intel i40en
• Intel ixgben
• Cisco nenic
• Broadcom bnxtnet

Скорее всего, новая версия VMware vSphere 6.7 Update 3 будет доступна для скачивания либо во время VMworld 2019, либо через несколько дней после его завершения. Следите за нашими обновлениями.

Компания VMware на днях объявила о скором выпуске новой версии решения для создания отказоустойчивых кластеров хранилищ - VMware vSAN 6.7 Update 3. Основная тема нововведений - поддержка облачных сред размещения виртуальных машин и работа с контейнеризованными приложениями.

Давайте посмотрим, что именно нового появилось в vSAN 6.7 Update 3:

1. Поддержка контейнеров приложений в облачных средах.

Контейнеры стали одной из главных моделей распространения приложений в облачной среде. Сама технология контейнеризации упрощает развертывание и обслуживание приложений, выделяя их в микросервисы, но все процессы вокруг них становятся сложнее (оркестрация, организация персистентных хранилищ, сетевая коммуникация).

vSAN 6.7 Update 3 имеет встроенные инструменты по организации постоянных хранилищ для контейнеров приложений, в том числе в облачных средах. Технология vSAN cloud native storage поддерживает все ключевые API-вызовы к хранилищам внутри кластеров Kubernetes через драйвер Container Storage Interface (CSI). Теперь разработчики смогут применять политики хранилищ SPBM при развертывании новых pods и монтировании томов с постоянными хранилищами, точно так же, как они делают это с виртуальными дисками машин.

Если же вы используете тома Virtual Volumes на платформе vSAN, то получите еще больше преимуществ:

• Развертывание хранилищ контейнеров через API параллельно с самими контейнерами.
• Возможность портирования приложений между частным и публичным облаком в рамках гибридной среды с поддержкой одного набора операций и инструментов.

2. Нативная гибридная среда инфраструктуры vSAN.

Сейчас гибридные среды становятся очень распространенной моделью доставки ИТ-сервисов, так как именно сочетание частного и публичного облаков дает самый большой эффект с точки зрения масштабирования и обеспечения показателей качества предоставления услуг. При этом администраторы хотят, чтобы приложения Docker также имели возможность бесшовно перемещаться между публичным и частным облаками со всеми их хранилищами.

Теперь vSAN предоставит интеграцию с сотнями облачных провайдеров, включая "большую четверку" Amazon, Microsoft, Google и IBM, которая позволит использовать тот же набор средств и утилит vSAN для хранилищ контейнеров в облаке, что и в частной инфраструктуре.

3. Унифицированные средства управления vSAN для контейнеров и виртуальных машин.

В одной виртуальной машине может быть много контейнеров приложений, вплоть до нескольких сотен. При возникновении проблем с хранилищем для одного из контейнеров становится очень и очень сложно понять ее причину. Теперь же vSAN предоставляет администраторам гранулярную видимость внутри ВМ до уровня контейнеров, что позволяет мониторить состояние отдельных хранилищ контейнеров на уровне томов для каждого из них.

В рамках единого пространства хранения можно анализировать использование емкости виртуальными машинами и контейнерами:

Все это позволит командам DevOps быстрее решать проблемы с хранилищами контейнеризованных приложений через стандартную консоль vSphere Client.

4. Интеллектуальные средства управления вводом-выводом.

Теперь vSAN еще более эффективно работает при обмене данными между буффером на чтение (write buffer) и пространством хранения (capacity tier). Особенно заметна эта оптимизация для последовательных операций записи (что очень актуально для процессов ресинхронизации и восстановления данных).

Адаптивная ресинхронизация теперь идет в рамках множества параллельных потоков, что увеличивает ее эффективность:

Также в vSAN 6.7 U3 появились дополнительные метрики, касающиеся использования CPU хост-серверов ESXi (особенно актуально для дедупликации, шифрования и компрессии). Кроме того, появилась новая команда vsantop, которая показывает эти и многие другие полезные метрики:

5. Прочие улучшения.

Тут собраны различные улучшения vSAN 6.7 Update 3:

• Механизмы управления емкостью были улучшены таким образом, чтобы запускать операцию ресинхронизации на базе доступной емкости. Если какая-то дисковая группа заполнена, то операции ресинхронизации ставятся на паузу, чтобы предотвратить повреждения хранилищ.
• Администратор может выбрать опцию автоматической или ручной ребалансировки данных в кластере. Така как каждая инфраструктура индивидуальна, доступна тонкая настройка механизма ребалансировки, в зависимости от потребностей администратора.
• Теперь применения политик SPBM идут пачками, что существенно ускоряет производительность при изменении структуры политик.
• Выполнение обслуживания или изменении конфигурации во время операций ресинхронизации может привести к неправильному завершению этого процесса, поэтому в SAN 6.7 U3 клиент vSphere Client лучше понимает, когда выполняется этот процесс, и не дает мешать ему.
• Механизм pre-check симуляции, который позволяет администратору понять, что произойдет в случае изменения конфигурации кластера или его обслуживания.
• При изменении конфигурации шифрования, компрессии или дедупликации требуется изменения формата дисков (Disk format changes, DFC). Если для этого процесса недостаточно ресурсов, то специальная проверка даст знать об этом еще до выполнения операции.
• vSAN теперь сам предлагает обновиться на новый мажорный релиз или накатить обновления.
• Ранее vSAN требовал, чтобы vCenter был той же версии или более новый, теперь же поддержка прошлых версий vCenter стала более гибкой.
• Теперь в vSAN 6.7 U3 проще включить vSAN Support Insight и взаимодействовать с поддержкой VMware.
• iSCSI LUN, презентованные из vSAN, теперь можно ресайзить без необходимости переводить том в оффлайн.
• SCSI-3 persistent reservations (SCSI-3 PR) теперь дают возможность нативной поддержки кластеров Windows Server Failover Clusters (WSFC), требующих общего диска.

Издание vSAN Enterprise Plus

Да, теперь VMware, как и для многих других продуктов, вводит издание Enterprise Plus для платформы vSAN. Эта лицензия будет включать в себя комбинацию продукта vSAN Enterprise и средства управления облачной средой vRealize Operations Advanced.

Все это даст следующую функциональность в связке двух решений:

• Географически растянутые кластеры с возможностями локальной защиты и синхронной репликацией.
• Средства нативного шифрования vSAN Encryption с поддержкой дедупликации и компрессии. В качестве провайдеров KMIP можно использовать такие решения, как CloudLink, Hytrust, SafeNet, Thales и Vormetric.
• Постоянная оптимизация производительности с возможностями предиктивной аналитики и проактивного планирования.
• Возможность интеллектуального решения проблем и продвинутый траблшутинг на базе аналитики метрик и логов с использованием средств обзора приложений на уровне всей инфраструктуры.

Более подробно о VMware vSAN 6.7 Update 3 мы узнаем на предстоящей конференции VMworld 2019, которая пройдет в конце августа в Сан-Франциско.

Вчера мы писали об очередной новинке на VMware Labs, мобильном клиенте vSphere Mobile Client для iOS и Android, а сегодня расскажем еще об одной утилите - Virtual Machine Compute Optimizer. Это средство представляет собой PowerShell-сценарий для модуля PowerCLI VMware.VimAutomation.Core, который собирает информацию о хостах ESXi и виртуальных машинах в вашем виртуальном окружении и выдает отчет о том, правильно ли они сконфигурированы с точки зрения процессоров и памяти.

Для этого в отчете есть колонка VMCPUsOptimized, которая принимает значения Yes или No.

Далее также идут колонки, где показаны оптимальные количества сокетов и ядер для виртуальных машин, которые было бы неплохо сделать для текущей конфигурации (OptimalSockets и OptimalCores). Текущая конфигурация также представлена в колонках VMNumSockets и VMCoresPerSocket.

Назначения колонок представлены на картинке ниже:

Надо понимать, что VMCO анализирует вашу инфраструктуру только на базе рекомендаций для оптимальной конфигурации виртуальных машин без учета реальной нагрузки, которая исполняется внутри. Для такой задачи нужно средство для сайзинга посерьезнее - например, VMware vRealize Operations Manager.

Скрипт Virtual Machine Compute Optimizer можно запускать как минимум под аккаунтом с правами на чтение инфраструктуры vCenter. Скачать его по этой ссылке.

Весной этого года мы писали о новой версии продукта VMware vRealize Network Insight (vRNI) 4.1, который позволяет системным и сетевым администраторам (а также администраторам информационной безопасности) наблюдать за сетевым взаимодействием в рамках виртуальной инфраструктуры и предпринимать действия по ее защите.

На днях VMware объявила о выпуске vRNI 4.2, давайте посмотрим, что там появилось нового.

1. Новые Data Sources

Теперь данные можно получать из следующих систем:

• Fortinet Firewall

Можно получить полный доступ к средствам управления Fortinet FortiManager, который управляет сетевыми экранами FortiGate. Это позволяет видеть всю инфраструктуру в контексте фаерволов, мгновенно видеть, какие правила привязаны к ВМ, получать сетевую топологию и многое другое.

• OpenShift Container Platform

В прошлой версии была добавлена поддержка VMware Enterprise PKS и ванильной инсталляции Kubernetes, а теперь поддержка была расширена функциями сетевой видимости, средствами обеспечения безопасности приложений, планирования миграции и решения проблем для небольших нагрузок.

• Кастомные Data Sources

Это называется User Assisted Network Information (U-AN-I). В рамках этого механизма вы можете ввести информацию о собственном коммутаторе или маршрутизаторе, который в дальнейшем будет добавлен в список поддерживаемых устройств. Но еще до полноценной поддержки это даст вам возможность просматривать пути VM-to-VM, дэшборд для коммутатора/маршрутизатора в рамках сетевой топологии, список всех интерфейсов, маршрутов, список VRF и т.п.

Также есть Python-библиотека, которая позволит автоматизировать сбор информации с устройств (маршруты, интерфейсы и т.д.) и загрузить ее в Network Insight. Саму эту задачу можно добавить в планировщик для регулярного обновления.

2. Метрики Network Latency.

Network Insight 4.2 представляет метрику задержки в 2 формах: TCP Round-Trip Time (RTT), которая привязана к сетевому потоку и метрика latency между отдельными компонентами (виртуальные и физические адаптеры NIC в рамках хоста ESXi).

Метрика TCP RTT может быть найден на дэшборде потока:

Также можно найти все потоки, время RTT которых больше 10 мс, следующей командой в поиске:

Average Tcp RTT of flow where Average Tcp RTT > 10ms

Кроме того, есть еще один наглядный способ увидеть все сетевые потоки вашей инфраструктуры на одной странице - надо пойти в Flow Insights и выбрать диаграмму Network Performance:

Из этого представления вы сразу поймете, какие потоки отрабатывают с самой большой задержкой, после чего можно углубиться в структуру потока и понять причину, по которой эта задержка столь велика.

С точки зрения измерения latency между компонентами, сейчас доступны следующие связки: vNIC к pNIC, pNIC к vNIC и vNIC к vNIC.

Надо отметить, что для получения данной информации вам потребуется NSX Data Center for vSphere версии 6.4.5 или выше.

3. Новые функции Application Discovery.

В Network Insight 4.1 появилась возможность обнаружения приложений без использования агентов с помощью трех методов:

• Использование тэгов рабочей нагрузки (workload tags)
• Иморт приложений из ServiceNow CMDB
• Использование паттерн наименования (naming convention)

Последний метод особенно актуален для облачных систем (например, инстансы AWS EC2), поэтому раньше пользователи должны были сами конструировать регулярные выражения, что непросто.

Теперь же в мастере application discovery wizard для этого есть Pattern Builder:

Также, начиная с vRNI 4.2, вы можете сохранять  application discovery runs как шаблоны, чтобы не конструировать регулярные выражения заново, что очень удобно.

4. Улучшения дэшборда Application Dashboard.

Это лучший дэшборд vRNI, который показывает все потоки между всеми обнаруженными приложениями в вашей инфраструктуре. В версии vRNI 4.1 его возможности были несколько ограничены, теперь же каждый поток визуализуется и детализируется, когда вы увеличиваете диаграмму и масштабируете его.

При этом с увеличением конкретного компонента увеличивается степень детализации, то есть включаются все виртуальные машины, контейнеры и т.п.

Полный список улучшений и нововведений находится в Release Notes. Скачать vRealize Network Insight 4.2 можно по этой ссылке.

Многие из администраторов VMware vSphere знают про механизм Storage I/O Control (SIOC) в платформе VMware vSphere (см. также наш пост здесь). Он позволяет приоритезировать ввод-вывод для виртуальных машин в рамках хоста, а также обмен данными хостов ESXi с хранилищами, к которым они подключены.

Сегодня мы поговорим о SIOC версии 2 и о том, как он взаимодействует с политиками Storage Policy Based Management (SPBM). Начать надо с того, что SIOC v2 полностью основан на политиках SPBM, а точнее является их частью. Он позволяет контролировать поток ввода-вывода на уровне виртуальных машин.

SIOC первой версии работает только с томами VMFS и NFS, тома VVol и RDM пока не поддерживаются. Он доступен только на уровне датасторов для регулирования потребления его ресурсов со стороны ВМ, настраиваемого на базе шар (shares). Там можно настроить SIOC на базе ограничения от пиковой пропускной способности (throughput) или заданного значения задержки (latency):

На базе выделенных shares виртуальным машинам, механизм SIOC распределит пропускную способность конкретного хранилища между ними. Их можно изменять в любой момент, перераспределяя ресурсы, а также выставлять нужные лимиты по IOPS:

Надо отметить, что SIOC v1 начинает работать только тогда, когда у датастора есть затык по производительности, и он не справляется с обработкой всех операций ввода-вывода.

Если же мы посмотрим на SIOC v2, который появился в VMware vSphere 6.5 в дополнение к первой версии, то увидим, что теперь это часть SPBM, и выделение ресурсов работает на уровне виртуальных машин, а не датасторов. SIOC v2 использует механизм vSphere APIs for I/O Filtering (VAIO), который получает прямой доступ к потоку ввода-вывода конкретной ВМ, вне зависимости от того, на каком хранилище она находится.

Таким образом, вы можете использовать SIOC v2 для регулирования потребления машиной ресурсов хранилища в любой момент, а не только в ситуации недостатка ресурсов.

Поэтому важно понимать, что SIOC v1 и SIOC v2 можно использовать одновременно, так как они касаются разных аспектов обработки потока ввода-вывода от виртуальных машин к хранилищам и обратно.

SIOC v2 включается в разделе политик SPBM, в секции Host-based rules:

На вкладке Storage I/O Control можно выбрать предопределенный шаблон выделения ресурсов I/O, либо кастомно задать его:

Для выбранной политики можно установить кастомные значения limit, reservation и shares. Если говорить о предопределенных шаблонах, то вот так они выглядят для варианта Low:

Так для Normal:

А так для High:

Если выберите вариант Custom, то дефолтно там будут такие значения:

Лимит можно задать, например, для тестовых машин, где ведется разработка, резервирование - когда вы точно знаете, какое минимальное число IOPS нужно приложению для работы, а shares можете регулировать долями от 1000. Например, если у вас 5 машин, то вы можете распределить shares как 300, 200, 100, 100 и 100. Это значит, что первая машина будет выжимать в три раза больше IOPS, чем последняя.

Еще один плюс такого назначения параметров SIOC на уровне ВМ - это возможность определить политики для отдельных дисков VMDK, на которых может происходить работа с данными разной степени интенсивности:

После того, как вы настроили политики SIOC v2, вы можете увидеть все текущие назначения в разделе Monitor -> Resource Allocation -> Storage:

Многим администраторам знакома такая вещь: сначала для теста устанавливается виртуальная машина VMware vCenter Server Appliance в конфигурации tiny (минимальные аппаратные настройки), а потом она приживается, и хочется сделать из нее полноценную производственную среду управления (конфигурацию large). Только вот не хочется ее переустанавливать.

Для тех, кто столкнулся с такой проблемой, Robert Szymczak написал полезный пост о том, как это сделать (но помните, что это неофициальная и неподдерживаемая процедура).

Установщик vCSA использует фреймворк Electron, настраивая конфигурацию через JSON, и механизм JSON-Schema для установки и валидации параметров. Поэтому в ISO-образе вы сможете найти конфигурацию сервера vCenter по следующему пути:

\vcsa-ui-installer\win32\resources\app\resources\layout.json

Там как раз и находятся данные о типовых конфигурациях vCSA. Например, так выглядит размер xlarge:

"xlarge": {
        "cpu": 24,
        "memory": 49152,
        "host-count": 2000,
        "vm-count": 35000,
        "disk-swap": "50GB",
        "disk-core": "100GB",
        "disk-log": "25GB",
        "disk-db": "50GB",
        "disk-dblog": "25GB",
        "disk-seat": "500GB",
        "disk-netdump": "10GB",
        "disk-autodeploy": "25GB",
        "disk-imagebuilder": "25GB",
        "disk-updatemgr": "100GB",
        "disk-archive": "200GB",
        "required-disk-space": "1180GB",
        "label": "X-Large vCenter Server with Embedded PSC",
        "description": "This will deploy a X-Large VM configured with 24 vCPUs and 48 GB of memory and requires 1180 GB of disk space will be updated for xlarge later. This option contains vCenter Server with an embedded Platform Services Controller for managing up to 2000 hosts and 35,000 VMs."
    }

Таким образом вы поймете, на какие именно конфигурации нужно изменить компоненты виртуальной машины с vCenter. Перед изменением конфигурации сделайте снапшот машины vCSA, который сохранит параметры ее виртуального аппаратного обеспечения.

Теперь переходим, собственно, к изменению самой конфигурации:

1. Увеличение CPU и памяти (RAM).

• Остановите машину.
• Хорошая идея - вывести ее ESXi-хост из кластера DRS.
• Зайдите на ESXi через Host Client, после чего в настройках ВМ измените конфигурацию CPU и памяти, чтобы выставить ее в соответствии с нужной конфигурацией.

2. Увеличение диска ВМ с сервером vCSA.

• Об увеличении дискового пространства сервера vCSA 6.5 мы писали вот в этой статье. С тех пор ничего особо не изменилось. Некоторую дополнительную информацию вы также можете получить в KB 2145603 на случай если что изменится в процедуре vCSA 6.x.
• Диски нужно настраивать не только по размеру, но и по корректной позиции в виртуальном слоте SCSI.

Примерно так это выглядит для vCenter 6.7 Update 2:

Помните, что иногда имя VMDK может не соответствовать его позиции в слоте SCSI. Например, встречаются случаи, когда VMDK0 смонтирован в слот SCSI(0:4), а VMDK2 - в слот SCSI(0:0). В этом случае реальным загрузочным диском будет VMDK2, а не VMDK0, несмотря на их названия.

Также обратите внимание, что SCSI слот 0:7 не используется - не ошибитесь.

После изменения этих параметров запустите vCenter и убедитесь, что все в порядке.

Вчера мы рассказали о новых возможностях платформы для виртуализации и доставки настольных ПК предприятия VMware Horizon 7.9, а сегодня поговорим о том, что нового появилось в клиентах.

Как обычно, VMware обновляет все клиенты для всех платформ (в этот раз - это Horizon Clients 5.1), в каждом из которых свой набор нововведений. Напомним, что о функционале vSphere Clients 5.0 мы писали в марте этого года вот тут.

Давайте посмотрим, что нового появилось в клиентах для различных платформ:

VMware Horizon Client 5.1 for Windows

• Улучшенная функциональность Drag and Drop.
  Пользователи могут перетаскивать текст, rich text, HTML, картинки и файловые объекты между клиентской системой и десктопом или опубликованным приложением. Эта функция требует Horizon Agent 7.9. Администратор может использовать настройки групповых политик или умные политики (Smart Policies) для настройки этого поведения. Более подробно об этом написано вот тут.
  
• Установка ярлыков для десктопа и приложений при запуске Horizon Client.
  Новая опция командной строки -installShortcutsThenQuit позволяет установить ярлыки десктопов и приложений, которые настроены на сервере, при запуске Horizon Client. При использовании этого параметра Horizon Client бесшумно соединяется с сервером, устанавливает ярлыки, после чего завершает работу. Подробнее об этом рассказано здесь.
• Поддержка Windows 10 Education.
  Можно установить Horizon Client for Windows на клиентскую систему Windows 10 с изданием Education edition.
• Перенаправление COM-портов в режиме вложенной виртуализации (nested mode).
  Теперь последовательный порт можно перенаправить при работе в nested mode. Как этим пользоваться указано в KB 67248.
• Фильтрация устройств и папок на стороне клиента.
  Администратор может принудительно включить или исключить папки или отдельные устройства на базе полей vendor и product ID из перенаправления через групповую политику. Шаблон VMware Horizon Client Drive Redirection ADMX (vdm_agent_cdr.admx) содержит две новых настройки групповых политик - Exclude Vid/Pid Device и Include Vid/Pid Device. Подробнее об этом написано вот тут.
• Изменение поддержки для нескольких мониторов.
  Обновленные спецификации дисплеев Windows требуют Windows 10 версии 1803 или более поздней для поддержки 6 мониторов. Подробнее об этом написано вот тут.

VMware Horizon Client 5.1 for Linux

• Возможность VMware Integrated Printing feature .
  Пользователи теперь могут применять функцию VMware Integrated Printing, чтобы печатать документы на сетевых принтерах или на привязанных локально устройствах. Эта возможность требует Horizon Agent 7.9.
• Улучшенная производительность с Lightweight Protocol Client.
  Horizon Client теперь использует драйвер Lightweight Protocol Client driver для рендеринга и прочей обработки данных. Этот драйвер имеет лучшую произодительность, чем драйвер протокола RMKS, использовавшийся в прошлых версиях Horizon Client. Лог-файлы, которые раньше содержали записи "RMKS" теперь содержат строчки "VIEWCLIENT".
• Поддержка аутентификации RSA SecurID и RADIUS в интерфейсе командной строки.
  Теперь интерфейс поддерживает логин с помощью аутентификации RSA SecurID и RADIUS без необходимости взаимодействия пользователя с клиентом Horizon Client. Пользователи могут ввести их учетные данные RSA SecurID или RADIUS, вызвав параметры командной строки --tokenUserName и --passcode. 
• Выбор конкретных мониторов для отдельных приложений.
  В многомониторной конфигурации клиентов для нужных опубликованных приложений можно выбрать мониторы, где они будут отображаться.
• Expanded support for serial port redirection
  Теперь последовательный порт можно перенаправить для десктопов с ОС Windows 7 и Windows 10, на которых установлен Horizon Agent 7.9 с опцией Serial Port Redirection. Также протокол PCoIP был полностью валидирован и поддерживается для этой возможности.
• Поддержка HTML5 Multimedia Redirection.
  Horizon Client for Linux теперь поддерживает перенаправление мультимедиа-контента на клиентскую систему из браузеров Google Chrome и Microsoft Edge, которые работают в удаленном десктопе. Эта функция снижает нагрузку на хосты ESXi и улучшает производительность аудио и видео для пользователя за счет локальной обработки потока.

VMware Horizon Client 5.1 for Android

• Поддержка 64-битной архитектуры Android.
  Теперь можно установить Horizon Client for Android на устройства Android с архитектурой ARM64 и x86_64.
• Функция Derived credentials для устройств Chromebook.
  Теперь можно создать виртуальную смарт-карту для логина на сервер и соединения со своим десктопом из устройства Chromebook. Более подробно об этом рассказано здесь.
• Поддержка IPv6 для Chromebook.
  Начиная с Horizon 7.9, вы можете использовать Horizon Client 5.1 for Android на устройствах Chromebook в окружениях с IPv6.

VMware Horizon Client 5.1 for Mac

• Фильтрация устройств и папок на стороне клиента.
  Администратор может принудительно включить или исключить папки или отдельные устройства на базе полей vendor и product ID из перенаправления через групповую политику. Шаблон VMware Horizon Client Drive Redirection ADMX (vdm_agent_cdr.admx) содержит две новых настройки групповых политик - Exclude Vid/Pid Device и Include Vid/Pid Device. Подробнее об этом написано вот тут.
• Поддержка драйверов смарт-карт CryptoTokenKit
  Для карт CAC и PIV Horizon Client for Mac теперь использует драйвер CryptoTokenKit по умолчанию, поэтому дополительно вам устанавливать ничего не нужно. Подробнее об этом рассказано здесь.
• Улучшенная функциональность Drag and Drop.
  Пользователи могут перетаскивать текст, rich text, HTML, картинки и файловые объекты между клиентской системой и десктопом или опубликованным приложением. Эта функция требует Horizon Agent 7.9. Администратор может использовать настройки групповых политик или умные политики (Smart Policies) для настройки этого поведения. Более подробно об этом написано вот тут.
• Возможность VMware Integrated Printing feature .
  Пользователи теперь могут применять функцию VMware Integrated Printing, чтобы печатать документы на сетевых принтерах или на привязанных локально устройствах. Эта возможность требует Horizon Agent 7.9. Подробнее об этом написано тут.
• Выбор конкретных мониторов для отдельных приложений.
  В многомониторной конфигурации клиентов для нужных опубликованных приложений можно выбрать мониторы, где они будут отображаться. Подробнее об этом тут.
• Поддержка Metal 
  Horizon Client for Mac теперь использует фреймворк Metal вместо OpenGL для рендеринга десктопов и опубликованных приложений.

VMware Horizon Client 5.1 for Chrome

• Поддержка Workspace ONE.
  Пользователи могут запускать приложения через Horizon Client for Chrome напрямую из VMware Workspace ONE.
• Поддержка бесшовных окон (Seamless Windows).
  Теперь можно использовать удаленный десктоп и опубликованные приложения так, как будто они запущены локально (то есть без сайдбара и верхнего меню).
• Управление настройками монитора через консоль Google Admin. 
  Администраторы могут теперь использовать Google Admin console для включения и отключения возможности нескольких мониторов и режима High Resolution Mode для определенных серверов Connection Server. Подробнее об этом тут.

VMware Horizon Client 5.1 for Windows 10 UWP

• Изменение доменной безопасности.
  Когда пользователь логинится в Horizon 7.8 или более поздней версии из Horizon Client 5.1 for Windows 10 UWP, ему может потребоваться ввести домен в поле User name (domain\username или username@domain.com). В зависимости от конфигурации сервера, комбобокс выбора домена может быть спрятан в целях безопасности (либо там может отображаться *DefaultDomain*). Подробнее об этом здесь.

Интересно, что в рамках этого релиза клиенты VMware Horizon Client 5.1 for iOS и VMware Horizon HTML Access 5.1 не получили никаких новых возможностей.

Скачать все клиенты VMware Horizon Client 5.1 можно будет скоро по этой ссылке.

В марте этого года компания VMware выпустила обновленную версию платформы для виртуализации и доставки настольных ПК предприятия VMware Horizon 7.8 (также мы писали о новых клиентах версии 5.0), а на днях вышло еще одно обновление этого решения - VMware Horizon 7.9. Давайте посмотрим, что интересного появилось в этом продукте...

На днях компания VMware выпустила третий пакет обновления для предыдущего поколения своей главной платформы виртуализации - VMware vSphere 6.5 Update 3. Напомним, что Update 2 вышел в мае прошлого года, так что давно было уже пора выпускать апдейт, так как версия 6.5 по-прежнему широко используется, особенно в крупных предприятиях.

Давайте посмотрим, что нового в vSphere 6.5 U3.

Новые функции vCenter 6.5 Update 3:

• События о добавлении, удалении и модификации пользовательских ролей содержат информацию о пользователе, который производит изменения.
• Улучшения возможностей аудита в компоненте VMware vCenter Single Sign-On - теперь появились события для следующих операций: управление пользователями, логин, создание групп, изменение источника идентификации, управление политиками. Доступна эта фича только для виртуального модуля vCSA с интегрированным Platform Services Controller. Поддерживаемые источники идентификации: vsphere.local, Integrated Windows Authentication (IWA) и Active Directory over LDAP.
• Поддержка новых внешних баз данных - добавлена поддержка Microsoft SQL Server 2014 SP3.
• Обновления ОС Photon для vCSA.

Release Notes для vCenter 6.5 U3 находятся здесь.

Новые функции ESXi 6.5 Update 3:

• Драйвер ixgben добавляет функцию queue pairing для оптимизации эффективности CPU.
• С помощью ESXi 6.5 Update 3 вы можете отслеживать использование лицензий и обновлять топологию коммутаторов. Также улучшения можно увидеть в Developer Center клиента vSphere Client.
• Поддержка устаревших серверов AMD Zen 2.
• Множество обновлений драйверов устройств: lsi-msgpt2, lsi-msgpt35, lsi-mr3, lpfc/brcmfcoe, qlnativefc, smartpqi, nvme, nenic, ixgben, i40en и bnxtnet.
• Поддержка Windows Server Failover Clustering и Windows Server 2019.
• Добавлено свойство com.vmware.etherswitch.ipfixbehavior в распределенные виртуальные коммутаторы, чтобы позволить пользователям выбирать способ трекинга входящего и исходящего трафика. Значение 1 включает сэмплирование для входящего и исходящего трафика, значение 0 включает его только для исходящего (значение по умолчанию).

Release Notes для ESXi 6.5 U3 находятся здесь.

Если вы ожидали среди возможностей чего-то действительно нового - увы, этого не бывает. VMware надо развивать ветку vSphere 6.7 и следующие версии платформы. Скачать VMware vSphere 6.5 Update 3 можно по этой ссылке.

Какие еще продукты VMware были обновлены параллельно с этим релизом:

• vSphere Replication 6.5.1.4 - просто обновление с исправлением ошибок.
• App Volumes 2.17 - поддержка Windows 10 1903, коммуникация с SQL Server по протоколу TLS 1.2. Остальное - здесь.
• User Environment Manager 9.8.0 - это большое обновление, подробнее о нем вот тут.

Некоторые пользователи, особенно после апгрейда сервера VMware vCenter Server Appliance 6.5 на версию 6.7, получают вот такое сообщение при попытке входа через интерфейс VAMI (Virtual Appliance Management Infrastructure):

Напомним, что интерфейс VAMI для управления виртуальным модулем vCSA доступен по ссылке:

https://<vCenter_FQDN>:5480

Причин проблемы может быть 2:

1. Пароль пользователя root устарел (кстати, помните, что в пароле нельзя использовать двоеточие). Для этого надо зайти в консоль vCSA и проверить это командой:

chage -l root

2. Не поднялась служба VMware Appliance Management Service.

Эта служба также кратко называется "applmgmt". Чтобы запустить ее через vSphere Client, зайдите в administrator@vsphere.local > Administration > Deployment > System Configuration > Services, выделите Appliance Management Service и нажмите Start.

Также можно сделать это из командной строки шелла vCSA:

service-control --start applmgmt

Далее нужно проверить, что служба действительно запустилась:

service-control --Status

Можно также поднять все сервисы vCSA одной командой:

service-control --start --all

Кстати, иногда после апгрейда хостов ESXi 6.5 на версию 6.7 внешний сервер Syslog может перестать принимать логи от vCSA из-за того, что правило фаервола ESXi для Syslog почему-то перестает быть активным. Можно снова включить это правило через интерфейс vSphere Client, либо вот такой командой PowerCLI:

Get-VMHost | Get-VMHostFirewallException | where {$_.Name.StartsWith(‘syslog’)} | Set-VMHostFirewallException -Enabled $true

Многие администраторы платформы VMware vSphere очень часто интересуются вопросом замены сертификатов для серверов ESXi в целях обеспечения безопасности. Как правило, это просто инструкции, которые не дают понимания - а зачем именно нужно менять эти сертификаты.

Недавно VMware выпустила интересную статью на тему сертификатов в vSphere и других продуктах, приведем ниже основные выдержки из нее.

1. Сертификаты - это вопрос доверия и шифрования.

При соединении с различными веб-консолями компонентов инфраструктуры VMware vSphere используется протокол HTTPS, где S означает "Secure". Инфраструктура SSL, а точнее ее последователь Transport Layer Security (TLS), использует известный в криптографии принцип открытого и закрытого ключей, который позволяет узлам, доверяющим друг другу безопасно обмениться информацией по шифрованному каналу.

TLS развивается по следующему пути:

• Версия 1.0 имеет уязвимости, он небезопасен и больше не должен использоваться.
• Версия 1.1 не имеет таких уязвимостей, как 1.0, но использует такие алгоритмы шифрования, как MD5 и SHA-1, которые больше не считаются безопасными.
• Версия 1.2 добавляет шифрование AES, которое работает быстро и не использует небезопасные методы, сам же алгоритм использует SHA-256. На текущий момент это стандарт TLS.
• Версия 1.3 не содержит слабых точек и добавляет возможности увеличения скорости соединения, этот стандарт скоро будет использоваться.

Если вы используете сертификаты vSphere, то независимо от того, какие они (самоподписанные или выданные центром сертификации) - общение между компонентами виртуальной инфраструктуры будет вестись посредством TLS с надежным шифрованием. Вопрос сертификатов тут - это всего лишь вопрос доверия: какому объекту, выпустившему сертификат, вы доверяете - это и есть Центр сертификации (он же Certificate Authority, CA).

Многие крупные компании, имеющие определенный вес (например, Microsoft) сами являются Центрами сертификации, а некоторые компании используют службы Microsoft Active Directory Certificate Services, чтобы встроить собственные CA в операционную систему и браузеры (импортируют корневые сертификаты), чтобы "научить" их доверять этим CA.

2. В VMware vSphere сертификаты используются повсеместно.

Как правило, они используются для трех целей:

• Сертификаты серверов ESXi, которые выпускаются для управляющих интерфейсов на всех хост-серверах.
• "Машинные" сертификаты SSL для защиты консолей, с которыми работает человек - веб-консоль vSphere Client, страница логина SSO или Platform Service Controllers (PSCs).
• "Solution"-сертификаты, используемые для защиты коммуникаций со сторонними к платформе vSphere продуктам, таким как vRealize Operations Manager, vSphere Replication и другим.

Полный список компонентов, где vSphere использует сертификаты, приведен вот тут.

3. vSphere имеет собственный Центр сертификации.

Платформа vSphere из коробки поставляется с собственным CA, который используется для коммуникации между компонентами. Называется он VMware Certificate Authority (VMCA) и полностью поддерживается для vSphere как с внешним PSC, так и для vCenter Server Appliance (vCSA) со встроенным PSC.

Как только вы добавляете хост ESXi в окружение vCenter, то VMCA, работающий на уровне vCenter, выпускает новый сертификат на этот ESXi и добавляет его в хранилище сертификатов. Такая же штука происходит, когда вы настраиваете интеграцию, например, с решениями vRealize Operations Manager или VMware AppDefense.

Надо понимать, что CA от VMware - это всего лишь решение для защищенной коммуникации между серверами, которое поставляется из коробки. Ваше право - доверять этой модели или нет.

4. Есть 4 способа внедрить инфраструктуру сертификатов на платформе vSphere.

Вот они:

• Использовать самоподписанные сертификаты VMCA. Вы можете просто скачать корневые сертификаты с веб-консоли vCenter, импортировать их в операционную систему клиентских машин. В этом случае при доступе к веб-консоли, например, vSphere Client у вас будет отображаться зеленый замочек.
• VMCA можно сделать подчиненным или промежуточным (subordinate/ intermediate) центром сертификации, поставив его посередине между CA и конечными хостами, что даст дополнительный уровень сложности и повысит вероятность ошибки в настройке. VMware не рекомендует так делать.
• Отключить VMCA и использовать собственные сертификаты для любых коммуникаций. Ваш ответственный за сертификаты должен нагенерировать запросы Certificate Signing Requests (CSR) для всех компонентов. Эти CSR-запросы вы отсылаете с CA, которому вы доверяете, получаете их подписанными, после чего устанавливаете их в ручном режиме. Это отнимает время и чревато ошибками. 
• Использовать гибридный подход - для хостов ESXi в их коммуникации с vCenter использовать самоподписанные VMCA сертификаты, а для веб-консолей vSphere Client и прочих использовать перевыпущенные сертификаты, которые надо установить на сервере vCenter и хостах, с которых будет управляться инфраструктура через браузер (тогда в нем появится зеленый замочек). Это самый рекомендуемый VMware вариант использования сертификатов.

5. Enterprise-сертификаты - тоже самоподписанные.

Подумайте - самоподписанными являются не только сертификаты VMCA, но и ваши корпоративные сертификаты. Если вы выпускаете эти сертификаты только на уровне своей компании, то у вас 2 точки потенциального недоверия - сторона, выпустившая сертификаты у вас в компании, а также, собственно, сам VMCA. Такая схема создает дополнительный уровень сложности администрирования, а также нарушения безопасности.

6. Не создавайте промежуточный Центр сертификации.

Если вы создаете intermediate CA (он же subordinate CA) для VMCA, превращая его в посредника, вы создаете потенциальную опасность для виртуальной инфраструктуры - если кто-то получает доступ к корпоративному центру сертификации и его парам ключей, то он может навыпускать любых сертификатов от имени VMCA и перехватывать потом любые коммуникации.

7. Можно изменять информацию для самоподписанных сертификатов CA.

С помощью утилиты  Certificate Manager utility вы можете сгенерировать новый VMCA с необходимой информацией о вашей организации внутри него. Эта утилита перевыпустит все сертификаты и заменит их на всех хостах виртуальной инфраструктуры. Это хорошая опция для гибридной модели. Кстати, вы можете менять даты устаревания сертификатов, если дефолтные вас не устраивают.

8. Тестируйте инфраструктуру сертификатов перед внедрением.

Вы можете развернуть виртуальную инфраструктуру и провести все эксперименты с сертификатами в виртуальной среде, где вы можете использовать виртуальные (nested) серверы ESXi. Приятная штука в том, что вы можете создавать снапшоты виртуальных машин, а значит в случае чего - быстро откатитесь на рабочий вариант. Еще одна среда для экспериментов - это облачная инфраструктура VMware Hands-on Labs, где можно безопасно ставить любые эксперименты.

Попробуйте также новую vSphere 6.7 Lightning Lab.

9. Делайте бэкапы своей инфраструктуры.

Делайте резервную копию вашего vCenter и PSC на уровне файлов через веб-консоль VAMI. Также утилитой Certificate Manager можно скопировать старый набор сертификатов перед развертыванием новых (но только один набор сертификатов, учитывайте это). Также эта процедура полностью поддерживается со стороны VMware Global Support Services.

10. Понимайте, зачем вы заморачиваетесь с заменой сертификатов.

Ответьте для себя на несколько вопросов:

• Стоит ли иконка зеленого замочка в браузере всех этих заморочек?
• Нужно ли всем видеть этот замочек или только команде администрирования vSphere?
• Почему вы доверяете vCenter для управления всем в виртуальной инфраструктуре, но не доверяете VMCA?
• В чем отличие самоподисанного сертификата вашего предприятия от самоподписанного сертификата VMCA?
• Действительно ли комплаенс требует от вас кастомных CA-сертификатов?
• Какова будет цена процедур по замене сертификатов в инфраструктуре vSphere во времени и деньгах?
• Увеличивает или уменьшает риск итоговое решение и почему конкретно?

Дополнительные ресурсы

• Живое кликабельное демо (feature walkthrough) о пошаговой настройке гибридного режима работы с сертификатами.
• Пост блога Adam Eckerle о гибридном режиме.
• Скачать корневые сертификаты VMCA root CA можно с главной страницы vCenter. В vSphere 6.7 ссылка расположена внизу справа.
• Wildcard-сертификаты не поддерживаются в среде vSphere.
• О сертификатах можно почитать в отличной документации по vSphere.
• Статьи Вильяма Лама о вложенных серверах ESXi.
• Статья о безотзывных сертификатах Active Directory Certificate Services.
• Как работает инфраструктура открытых ключей (пост EFF).
• При замене сертификатов подготовьте для тестирования несколько браузеров и научитесь быстро чистить в них кэш.
• Мы писали об утилите SDDC Certificate Tool, которая позволит вам просто заменить сертификаты во всем окружении vSphere.
• Архитектура VMware Cloud Foundation имеет средства по автоматизации управления жизненным циклом сертификатов.

Это гостевой пост компании ИТ-ГРАД, предоставляющей виртуальные машины из облака в аренду. VMware обновили свой гипервизор ESXi. Теперь скорость работы виртуальных графических процессоров под его управлением сопоставима с возможностями их bare metal реализаций — разница составляет всего 3%. Рассказываем, как компании удалось этого добиться...

Июнь оказался весьма богат на новые релизы на сайте проекта VMware Labs - недавно мы писали про обновление Horizon DaaS Migration Tool 2.1 для миграции облака DaaS, новое средство Flowgate для агрегации метрик, обновления HCIBench и USB Network Native Driver for ESXi.

Но на этом релизы не остановились - на днях VMware выпустила обновленную утилиту IOBlazer, которая позволяет сгенерировать нагрузку на хранилища с любых платформ - Linux, Windows и OSX. Утилита была выпущена еще в 2011 году, но с тех пор не дорабатывалась, а вот на днях мы увидели ее версию 1.01.

Основная фича утилиты - возможность тонко кастомизировать параметры нагрузки на хранилище изнутри виртуальной машины, такие как размер IO и паттерн нагрузки, пакетирование (объем исходящих операций ввода-вывода), временные промежутки между пакетами, микс трафика чтения/записи, буфферизованные или прямые операции ввода-вывода и многое другое.

IOBlazer также может "проигрывать" записанные логи VSCSI, которые были получены за счет использования утилиты vscsiStats. В качестве метрик производительности можно получить пропускную способность в IOPS и в мегабайтах в секунду, а также задержки ввода-вывода (IO latency). Это дает возможность IOBlazer сгенерировать синтетическую нагрузку на диск виртуальной машины, которая соответствует реальной нагрузке, с возможностью ее повторения в любой момент.

IOBlazer вырос из минималистичного эмулятора MS SQL Server, который бы сфокусирован на эмуляции только нагрузки по вводу-выводу. Ранее утилита имела очень ограниченные возможности по генерации нагрузки по модели MS SQL Server IO (Асинхронность, небуфферизованные IO, параметры Gather/Scatter), теперь же все стало существенно лучше. Но 2 ограничения все еще остаются:

1. Выравнивание доступа к памяти по 4 КБ (страница памяти).

2. Выравнивание операций доступа к диску по 512 байт (дисовый сектор).

Утилиту не надо устанавливать - она запускается из дистрибутива. Инструкции можно найти в файле README. Скачать IOBlazer 1.01 можно по этой ссылке. В комплекте также идет исходник на C, который вы можете собрать самостоятельно.

Как знают почти все администраторы платформы VMware vSphere, для кластеров VMware HA/DRS есть такой режим работы, как Enhanced vMotion Compatibility (EVC). Нужен он для того, чтобы настроить презентацию инструкций процессора (CPU) хостами ESXi так, чтобы они в рамках кластера соответствовали одному базовому уровню (то есть все функции процессоров приводятся к минимальному уровню с набором инструкций, которые гарантированно есть на всех хостах).

Ввели режим EVC еще очень давно, чтобы поддерживать кластеры VMware vSphere, где стоят хосты с процессорами разных поколений. Эта ситуация случается довольно часто, так как клиенты VMware строят, например, кластер из 8 хостов, а потом докупают еще 4 через год-два. Понятно, что процессоры уже получаются другие, что дает mixed-окружение, где по-прежнему надо перемещать машины между хостами средствами vMotion. И если набор презентуемых инструкций CPU будет разный - двигать машины между хостами будет проблематично.

EVC маскирует инструкции CPU, которые есть не на всех хостах, от гостевых ОС виртуальных машин средствами интерфейса CPUID, который можно назвать "API для CPU". В статье VMware KB 1005764 можно почитать о том, как в кластере EVC происходит работа с базовыми уровнями CPU, а также о том, какие режимы для каких процессоров используются.

Надо отметить, что согласно опросам VMware, режим кластера EVC используют более 80% пользователей:

В VMware vSphere 6.7 появились механизмы Cross-Cloud Cold и Hot Migration, которые позволяют переносить нагрузки в онлайн и офлайн режиме между облаками и онпремизной инфраструктурой.

Когда это происходит, виртуальной машине приходится перемещаться между хостами с разными наборами инструкций процессора. Поэтому, в связи с распространением распределенных облачных инфраструктур, в vSphere появилась технология Per-VM EVC, которая позволяет подготовить виртуальную машину к миграции на совершенно другое оборудование.

По умолчанию, при перемещении машины между кластерами она теряет свою конфигурацию EVC, но в конфигурации ВМ можно настроить необходимый базовый уровень EVC, чтобы он был привязан к машине и переезжал вместе с ней между кластерами:

Обратите внимание, что Per-VM EVC доступна только, начиная с vSphere 6.7 и версии виртуального железа Hardware Version 14. Эта конфигурация сохраняется в vmx-файле (потому и переезжает вместе с машиной) и выглядит следующим образом:

featMask.vm.cpuid.Intel = “Val:1”
featMask.vm.cpuid.FAMILY = “Val:6”
featMask.vm.cpuid.MODEL = “Val:0x4f”
featMask.vm.cpuid.STEPPING = “Val:0”
featMask.vm.cpuid.NUMLEVELS = “Val:0xd”

Некоторые пользователи не включают EVC, так как покупают унифицированное оборудование, но VMware рекомендует включать EVC в кластерах со старта, так как, во-первых, никто не знает, какое оборудование будет докупаться в будущем, а, во-вторых, так будет легче обеспечивать миграцию виртуальных машин между облачными инфраструктурами.

Основная причина, по которой не включают EVC - это боязнь того, что поскольку машины не будут использовать весь набор инструкций CPU (особенно самых последних), то это даст снижение производительности. Поэтому VMware написала целый документ "Impact of Enhanced vMotion Compatibility on Application Performance", где пытается доказать, что это не сильно влияет на производительность. Вот, например, производительность Oracle на выставленных базовых уровнях для разных поколений процессоров (в документе есть еще много интересных графиков):

Чтобы включить EVC на базе виртуальной машины, нужно ее выключить, после чего настроить нужный базовый уровень. Для автоматизации этого процесса лучше использовать PowerCLI, а сама процедура отлично описана в статье "Configuring Per-VM EVC with PowerCLI".

Для того, чтобы выяснить, какие базовые уровни EVC выставлены для виртуальных машин в кластере, можно использовать следующий сценарий PowerCLI:

Get-VM | Select Name,HardwareVersion,
@{Name='VM_EVC_Mode';Expression={$_.ExtensionData.Runtime.MinRequiredEVCModeKey}},
@{Name='Cluster_Name';Expression={$_.VMHost.Parent}},
@{Name='Cluster_EVC_Mode';Expression={$_.VMHost.Parent.EVCMode}} | ft

Это даст примерно следующий результат (надо помнить, что отчет будет сгенерирован только для VM hardware version 14 и позднее):

В примере выше одна машина отличается от базового уровня хостов, но в данном случае это поддерживаемая конфигурация. Проблемы начинаются, когда машина использует более высокий базовый уровень CPU, чем его поддерживает хост ESXi. В этом случае при миграции vMotion пользователь получит ошибку:

Понять максимально поддерживаемый режим EVC на хосте можно с помощью команды:

Get-VMHost | Select-Object Name,ProcessorType,MaxEVCMode

В итоге вы получите примерно такой отчет:

В целом тут совет такой - включайте режим Enhanced vMotion Compatibility (EVC) в кластерах и для виртуальных машин VMware vSphere сейчас, чтобы не столкнуться с неожиданными проблемами в будущем.

На сайте VMware Labs обновилась утилита HCIBench до версии 2.1.

Напомним, что о версии HCIBench 2.0 мы писали вот тут, а здесь мы рассматривали использование этой утилиты для замеров производительности кластеров VMware vSAN. Напомним, что это средство позволяет провести комплексный тест производительности отказоустойчивых кластеров хранилищ Virtual SAN, а также других конфигураций виртуальной инфраструктуры.

Проект HCIbecnh ("Hyper-converged Infrastructure Benchmark") является оберткой для известного open source теста VDbench, он позволяет организовать автоматизированное тестирование гиперконвергентного кластера (HCI-кластера). Гиперконвергентный кластер - это когда все его вычислительные ресурсы, системы хранения и сети виртуализованы и собраны в единую интегрированную сущность и управляются из одной точки.

Целью такого тестирования может быть, например, необходимость убедиться, что развернутая инфраструктура обеспечивает достаточную производительность для планируемой на нее нагрузки.

Что нового появилось в HCIBench 2.1:

• Интерфейс переключили на темную тему.
• Переработанная технология подготовки VMDK, которая теперь работает гораздо быстрее за счет использования рандомизации на дедуплицированных хранилищах.
• Добавлена возможность обновления процесса подготовки VMDK.
• Добавлена проверка портов базы данных Graphite в процесс превалидации.
• Пароли vCenter и хостов ESXi затемняются при сохранении
• Добавлена кнопка удаления гостевой ВМ ("Delete Guest VM").
• Пофикшены проблемы с дисплеями для Grafana.
• Пофикшена проблема с пустыми результатами при отработки модели нагрузки FIO (Flexible I/O).
• Множество мелких исправлений ошибок.

Скачать HCIBench 2.1 можно по этой ссылке. Документация пока доступна только для версии 2.0.

На сайте проекта VMware Labs появилось очередное обновление - стала доступна новая версия средства USB Network Native Driver for ESXi до версии 1.1. Напомним, что ранее мы писали о нем вот тут. Это нативный драйвер для сетевых адаптеров серверов, которые подключаются через USB-порт.

Такой адаптер можно использовать, когда вам необходимо, например, подключить дополнительные Ethernet-порты к серверу, а у него больше не осталось свободных PCI/PCIe-слотов. В каких-то еще случаях подключение такого адаптера может помочь, чтобы получить еще одно сетевое соединение без необходимости перезагружать сервер (и так же просто отключить его).

Новая версия драйвера содержит поддержку девяти новых устройств USB NIC, включая девайсы USB 2.0 RTL8152 & TPLINK. Полный список поддерживаемых устройств теперь таков:

Помимо этого, в драйвер также была добавлена поддержка Jumbo Frames (размером до 4K) для устройств RTL8153 и AX88179.

Для установки драйвера нужно развернуть на ESXi 6.5 или 6.7 один из двух VIB-пакетов для соответствующей версии:

• ESXi670-VMKUSB-NIC-FLING-20124247-offline_bundle-11613968
• ESXi650-VMKUSB-NIC-FLING-20123976-offline_bundle-11613344

Делается это следующей командой:

esxcli software vib install -d /path/to/the/offline/bundle

После установки нужно перезагрузить хост VMware ESXi, после чего устройство USB NIC будет автоматически смонтировано как, например, vusb0.

Скачать USB Network Native Driver for ESXi можно по этой ссылке.

У средства обновления хостов VMware vSphere Update Manager (VUM) есть полезный механизм проверок Pre-Check Remediation Report, который выполняет предварительную проверку условий для обновления хостов ESXi, чтобы этот процесс не прервался уже после его начала. Эти условия очень просты, но иногда позволяют сэкономить массу времени, особенно в большой инфраструктуре VMware vSphere.

Чтобы запустить эти проверки, надо выбрать нужный вам кластер и нажать кнопку Pre-Check Remediation:

После того, как вы запустите предпроверку Update Manager, вы получите отчет с предупреждениями о фактах, мешающих дальнейшим обновлениям:

Отчет Pre-Check Remediation Report для кластера может содержать следующие пункты:

Отчет Pre-Check Remediation Report для виртуальных машин может содержать следующее:

Компания VMware опубликовала уведомление VMSA-2019-0009 для пакета VMware Tools, который содержит уязвимость, позволяющую непривилегированному пользователю читать данные из гостевой ВМ, а также негативно влиять на ее гостевую ОС. Уязвимости подвержены версии VMware Tools ниже 10.3.10.

В качестве примера использования такой уязвимости можно привести Windows-машины, где включены службы Microsoft Remote Desktop Services. Также риску подвержены службы Microsoft SQL Server или IIS, использующие сервисные аккаунты.

Сначала надо вывести все ВМ, имеющие VMware Tools версии ниже 10.3.10 с помощью следующей команды PowerCLI:

Get-VM | Where-Object {$_.Guest.ToolsVersion -lt ‘10.3.10’} | Sort-Object Name | Format-Table

Вот такая команда выдаст все Windows-машины с VMware Tools ниже, чем 10.3.10:

Get-VM | Where-Object {$_.Guest.ToolsVersion -lt ‘10.3.10’ -and $_.Guest.GuestFamily -eq ‘windowsGuest’} | Sort-Object Name | Format-Table

Проверить версию VMware Tools можно и самостоятельно в VMware vSphere Client:

Помните, что VMware 6.7 Update 2a идет с версией VMware Tools 10.3.5. Надо отметить, что гостевые ОС Linux не подвержены уязвимости, поэтому не пугайтесь, что open-vm-tools имеют только версию 10.3.5.

Последнюю же версию пакета тулзов можно скачать по этой ссылке: https://www.vmware.com/go/tools.

Если вы хотите обновить VMware Tools через офлайн-бандл, то скачайте "VMware Tools Offline VIB Bundle", после чего можно использовать vSphere Update Manager (VUM) для развертывания установщиков пакета на хостах ESXi без простоя. После этого машины должны в течение 5 минут схватить новую версию тулзов (таков период обновления информации об актуальной версии пакета). Установленная версия VMware Tools также проверяется и при vMotion, а, кроме того, и при операциях с питанием ВМ (включение/выключение).

В большой инфраструктуре вы можете настроить централизованный репозиторий VMware Tools для использования в качестве источника для многих хостов ESXi.

Обновление VMware Tools можно инициировать через PowerCLI с помощью следующего командлета:

Get-VM | Where-Object {$_.ExtensionData.Guest.ToolsVersionStatus -eq "guestToolsNeedUpgrade" -and $_.PowerState -eq "PoweredOn"} | Get-VMGuest | Where-Object {$_.GuestFamily -eq "windowsGuest" } | Update-Tools -NoReboot -RunAsync

Помните, что при апгрейде VMware Tools вам может потребоваться перезагрузка виртуальных машин и их гостевых ОС. Также вы можете использовать приведенный выше сценарий для нескольких ВМ в одной папке:

Get-VM “TEST-VM-02” | Where-Object…
Get-Folder “Test VMs - Snapshotted" | Get-VM | Where-Object…

Через vSphere Client тулзы также прекрасно обновляются:

Если вы используете опцию "Automatic Upgrade", то машина будет обновлена автоматически (без взаимодействия с гостевой ОС) и, при необходимости, перезагрузится. Также вы можете использовать обновление тулзов без немедленной перезагрузки, применив инструкции, описанные в KB1018377. Надо помнить, что в этом случае до перезагрузки будет работать старая версия VMware Tools, а значит, что до перезагрузки машины уязвимость будет актуальна.

Еще одна опция - настроить обновления тулзов в настройках виртуальной машины:

Иногда администраторы гостевой системы имеют эксклюзивный доступ к ней (например, админы бизнес-критичных баз данных) и контролируют все происходящие в ней события. Для этого надо настроить их взаимодействие с машиной как указано в KB 2007298.

В этом случае они получат нотификацию о новой версии VMware Tools из трея, либо могут проверить наличие обновлений самостоятельно с помощью команд:

• VMwareToolboxCmd.exe –v - проверка установленной версии.
• VMwareToolboxCmd.exe upgrade status - возможность обновления для доступных апгрейдов.
• VMwareToolboxCmd.exe upgrade start - запуск процедуры апгрейда.

В этом случае запустится графический установщик, но не требующий вмешательства пользователя.

Администраторы отказоустойчивых кластеров хранилищ VMware vSAN часто сталкиваются с проблемами производительности, наблюдаемыми в виртуальной среде. Как правило, о таких проблемах администратор узнает двумя путями: либо ему сообщают пользователи, либо он видит алерты, которые генерируются в консоли клиента vSphere Client при превышении определенных пороговых значений.

Так или иначе, администратор должен, прежде всего, выяснить, что проблема низкой производительности приложений проявляет себя именно на уровне гостевой системы. В этом случае VMware предлагает придерживаться следующего рабочего процесса:

Основные моменты траблшутинга по такому воркфлоу рассказаны в документе "Troubleshooting vSAN Performance". Самый очевидный симптом проблем - это задержки (Latency) на уровне гостевой ОС (то есть время, затраченное на выполнение транзакции ввода-вывода), которые приводят к медленной работе приложений.

Задержки измеряются в миллисекундах, и интерпретация их значений зависит от контекста - размер блока ввода-вывода, характер потока (чтение/запись, последовательное/случайное). При этом latency измеряется на некотором сегменте прохождения команд к хранилищу, на каждом из участков которого также возникают свои составляющие задержек. Анализ таких компонентов Storage stack в контексте задержек и поиск узких мест - и есть основная задача администратора, решающего проблемы низкой производительности приложений для пользователей. Многое из этого можно делать с помощью утилиты ESXTOP, о которой мы много писали.

Обратите внимание, что на иллюстрации фреймворка выше, анализ виртуальной инфраструктуры и анализ приложений и их рабочих процессов находится еще до анализа метрик. Это связано с тем, что выбор метрик, на которые стоит обратить внимание в среде VMware vSAN, зависит от характера происходящих проблем.

После того, как администратор выяснил основные признаки проблемы и локализовал ее на уровне приложений, можно приступать к анализу метрик. Алгоритм действий приведен в документе "Troubleshooting vSAN Performance":

Тут рекомендуется делать следующее:

• Шаг 1 - просматриваем метрики в гостевой ОС проблемной ВМ, чтобы убедиться, что проблемы с производительностью хранилища ощущаются на уровне приложений.
• Шаг 2 - просматриваем метрики на уровне кластера vSAN, чтобы в целом понять масштаб проблемы - нет ли других аномалий в кластере. Это позволяет идентифицировать потенциальные "наводки" от других компонентов виртуальной инфраструктуры.
• Шаг 3 - просматриваем метрики на уровне хоста ESXi, чтобы соотнести метрики внутри гостевой ОС и всего хоста в целом с точки зрения latency.
• Шаг 4 - смотрим на хосте метрики дисковой группы, чтобы найти источник повышенной latency.
• Шаг 5 - если не нашли проблему на шаге 4, то смотрим на сеть хоста и метрики VMkernel, чтобы убедиться, что сеть функционирует штатно.

То есть смысл прост - если что-то тормозит в кластере VMware vSAN, то это либо дисковая подсистема, либо сетевая инфраструктура. Ну и главное - правильно идентифицировать хост/хосты ESXi, где находятся компоненты виртуальной машины.

И еще одна важная рекомендация - при траблшутинге старайтесь не менять несколько настроек одновременно, чтобы решить проблему. Во-первых, вы не сможете понять, какая из настроек или их комбинация дала правильный эффект, а, во-вторых, вы не сразу можете обнаружить, что сделанные вами настройки может и помогли машине работать быстрее, но остальные машины этого хоста или кластера значительно просели по производительности. А вернуть все назад может быть не так уж и просто.

Для многих пользователей публичного облака VMware vCloud on AWS одним из первых возникает вопрос - как предоставить доступ из виртуальной машины в сети Compute Network в сеть SDDC Management Network, например, для целей управления сервисами vCenter или другими службами виртуального датацентра?

Также этот вариант использования может быть востребован, когда вам требуется доступ к управляющим компонентам посредством таких интерфейсов, как PowerCLI, или развертывание виртуальных сервисов с помощью утилиты OVFTool. Вильям Лам написал об этом хорошую статью, и мы приведем здесь ее основные моменты.

Естественно, что для целей обеспечения безопасности в облаке, эти две сети по умолчанию разделены. Первое, что вам нужно сделать - это понять, с каким типом решения NSX для управления сетью вы работаете (NSX-T или NSX-V). Сделать это можно с помощью вот этой статьи.

Процедура для NSX-V

В среде NSX-V вам нужно настроить IPsec VPN между компонентами Management Gateway (MGW) и Compute Gateway (CGW) перед тем, как заработает коммуникация между сетями.

Для настройки VPN для компонента Management Gateway нажимаем Add VPN в консоли VMC и вводим требующуюся информацию сетевой идентификации (публичный IP удаленного шлюза, параметры удаленной сети и ключи), что должно отражать конфигурацию Compute Gateway (остальные настройки можно оставить по умолчанию).

Далее надо настроить VPN для Compute Gateway путем выполнения тех же шагов, что и в предыдущем абзаце, только указав конфигурацию шлюза Management Gateway. После того, как настройки обеих VPN будут сохранены, начнет отображаться статус "Partially Connected". Потом нажимаем ссылку Actions в правом верхнем углу, выбираем Edit и сохраняем настройки еще раз, чтобы на обоих шлюзах показался статус "Connected":

Теперь надо настроить сетевой экран Compute Gateway Firewall, чтобы разрешить исходящие соединения в SDDC Management Network по порту 443 для требуемых ВМ (этот порт используется для vSphere Client, а также для доступа через средства OVFTool и PowerCLI).

В приведенном ниже примере машина имеет адрес 192.168.1.4, и мы хотим позволить ей общаться с сетью 10.2.0.0/16 через порт 443:

Теперь нужно добавить в фаервол Management Gateway Firewall правила для разрешения входящих соединений для vCenter Server и хостов ESXi по порту 443 от наших определенных ВМ. Здесь все точно так же - указываем IP машины 192.168.1.4, и нам нужно добавить 2 правила для входящего трафика для разрешения коммуникации со средствами управления виртуальной инфраструктурой:

После этого вы можете залогиниться в виртуальную машину и использовать средства управления платформой vSphere, например, применять утилиту импорта виртуальных модулей OVFTool, как рассказано тут.

Процедура для NSX-T

В среде NSX-T вам не нужно создавать VPN для получения функциональности маршрутизации, которая изначально заложена в маршрутизаторе T0, ведь обе сети Management и Compute Network присоединены к T0. Между тем, правила сетевого экрана добавлять, конечно же, нужно.

В решении NSX-T используются сущности Inventory Groups, чтобы сгруппировать набор виртуальных машин и/или IP-адреса/сети, которые можно использовать при создании правил сетевого экрана.

Создаем две Inventory Groups для нашей Compute Group - одну для нашей виртуальной машины и одну для того, чтобы представлять сеть Management Network. Идем в Groups и в левой части выбираем пункт "Workload Groups", где создаем 2 группы:

• Windows10 с Member Type вида Virtual Machine и указываем ВМ из инвентаря.
• VMC Management Network с Member Type вида IP Address и указываем сетевой диапазон 10.2.0.0/16.

Теперь нужно создать еще одну Inventory Group для нашей Management Group, которая будет отражать ВМ, для которой мы хотим сделать доступ. Чтобы это сделать, идем в Groups, выбираем "Management Groups" и создаем следующую группу:

• Windows10 Private IP с Member Type вида IP Address и указываем частный IP-адрес ВМ (в данном случае это 192.168.1.2).

Не забывайте нажать кнопку Publish, чтобы сохранить и применить правило сетевого экрана.

Теперь нужно создать правило сетевого экрана, чтобы разрешить Compute Gateway исходящие соединения к SDDC Management Network по порту 443 для нужных ВМ. Идем в Gateway Firewall и выбираем "Compute Gateway", где создаем новое правило, которое отражает группу Windows 10 как источник и группу VMC Management Network как назначение, а в качестве сервиса выбираем HTTPS (помним также про кнопку Publish).

Теперь надо создать правила на уровне Management Gateway, чтобы разрешить входящие соединения к хостам vCenter Server и ESXi по порту 443 из нужных нам ВМ. Идем в Gateway Firewall, слева выбираем "Management Gateway", затем создаем правило, которое отражает группу Windows 10 как источник, а в качестве группы назначения указываем vCenter и ESXi (сервис ставим также HTTPS):

После выполнения этой процедуры вы сможете залогиниться в ВМ Windows и использовать утилиту OVFTool для импорта/экспорта ВМ в ваш виртуальный датацентр (см. также данную процедуру здесь).

Если все было сделано правильно, вы должны иметь возможность доступа к интерфейсу vSphere Client из нужной вам ВМ, а также возможность выполнять сценарии PowerCLI и использовать утилиту OVFTool, как показано на скриншоте ниже:

Те, кто используют серверы HPE ProLiant с гипервизором VMware ESXi и пакетом управления HPE Agentless Management (AMS) для кастомизированных образов ESXi от HP, могут столкнуться со следующим сообщением об ошибке в клиенте vSphere Client:

The ramdisk 'tmp' is full

Выглядит это чаще всего вот так:

Проблема актуальна для всех версий VMware ESXi 6.0, VMware ESXi 6.5 и VMware ESXi 6.7 с пакетом Agentless Management Service (AMS) версии 11.4.0.

Если зайти в консоль ESXi и выполнить там команду vdf, то можно увидеть, что раздел /tmp заполнен на 99%:

В самом же разделе tmp есть файлик ams-bbUsg.txt, который и является источником проблем:

Для временного решения этой проблемы нужно просто удалить этот файлик, и сообщения об ошибке прекратятся. Но чтобы этого не происходило, надо обновить ваш пакет HPE Agentless Management (AMS) версии 11.4.0, где проявляется данная проблема, на версию 11.4.2. О том, как это сделать написано в статье базы знаний HP:

Advisory: VMware - VMware AMS Data File Filling Up Tmp May Cause VUM Updates to Fail On HPE Servers Running VMware ESXi 6.0/6.5/6.7 with AMS Version 11.4.0.

Сам репозиторий с обновленным AMS находится по следующей ссылке:

http://vibsdepot.hpe.com/hpe/may2019

В августе прошлого года мы сделали статью о новом виде памяти Persistent memory (PMEM) в VMware vSphere, которая находится на уровне между DRAM и Flash SSD с точки зрения производительности:

Надо сказать, что устройства с Persistent Memory (они же, например, девайсы с Intel Optane Memory) уже начинают рассматривать некоторые пользователи для внедрения в своей виртуальной инфраструктуре, поэтому надо помнить об их ограничениях, которые раскрыл Дункан Эппинг.

С точки зрения предоставления памяти PMEM виртуальной машине, на платформе vSphere есть 3 способа:

• vPMEMDisk - vSphere представляет PMEM как обычный диск, подключенный к виртуальной машине через контроллер SCSI. В этом случае ничего не нужно менять для гостевой ОС или приложений. В таком режиме работают любые системы, включая старые ОС и приложения.
• vPMEM - vSphere представляет PMEM как устройство NVDIMM для виртуальной машины. Большинство последних версий операционных систем (например, Windows Server 2016 и CentOS 7.4) поддерживают устройства NVDIMM и могут предоставлять их приложениям как блочные или байт-адресуемые устройства. Приложения могут использовать vPMEM как устройство хранения через тонкий слой файловой системы direct-access (DAX), либо замапить регион с устройства и получать к нему прямой доступ через байтовую адресацию. Такой режим может быть использован старыми или новыми приложениями, но работающими в новых версиях ОС, при этом версия Virtual Hardware должна быть не ниже 14.
• vPMEM-aware - это то же самое, что и vPMEM, но только с дополнительными возможностями приложения понимать, что машина использует такое устройство, и пользоваться его преимуществами.

Если виртуальная машина использует такие устройства, то она имеет очень существенные ограничения, которые на данный момент препятствуют их использованию в производственной среде. Они приведены в документе "vSphere Resource Management Guide" на странице 47 внизу. А именно:

• vSphere HA - полностью не поддерживается для машин с включенными vPMEM устройствами, вне зависимости от режима использования.
• vSphere DRS - полностью не поддерживается для машин с включенными vPMEM устройствами (машины не включаются в рекомендации и не мигрируют через vMotion), вне зависимости от режима использования.
• Миграция vMotion для машин с устройствами vPMEM / vPMEM-aware доступна только на хосты с устройствами PMEM.
• Миграция vMotion машин с устройством vPMEMDISK возможна на хост без устройства PMEM.

Будем надеяться, что эта ситуация в будущем изменится.